A.C.E. 2/ACE CD 2.iso/FILES/DOCS/AMOSDOC.LHA/AmosV1.3Update.doc

Text File | 1994-11-27 | 31KB | 788 lines

                      _____   _________________________
                     /    /  /                         \
                    /    /  /   ____________     ___    \
                   /    /  /   /           /    /   \    \
                  /    /  /   /_____      /    /     \    \
                 /    /  /          \    /    /       \    \
                /    /   \_____     /   /    /         \    \
               /    /         /    /   /    /           \    \
              /    /_________/    /   /    /_____________|    |
             |                   /   |                        |
             |__________________/    |________________________|



                        AMOS VERSION 1.3 UPDATE

                               WHAT'S NEW!


Typed by SIDEWINDER of LSD.
Manual supplied by SCOOTER.


INTRODUCTION
AMOS Basic has gone through a number of changes during the course of its
existence.  Rather than rest on our laurels, we've steadily updated the
system to include many new features suggested by AMOS users.  Incredibly
enough, we've placed these improvements on the public domain.  Special
updater disks are available from the AMOS user group or your local PD
library.  So whatever your version of AMOS Basic, you can upgrade to the
latest system for the price of a disk.

Here's a list of the versions of AMOS Basic to date:

AMOS 1.1

The original!

AMOS 1.2

This includes several new commands such as BANK SWAP.  There was also a
whole new set of SPRITE flipping routines introduced which allowed you to
display a single image in several orientations.
        The file-selector was completely reworked, and allowed you to change
the current disk by pressing the RIGHT mouse button and simply clicking
on the new device name with the mouse.  The UP/DOWN arrows were
repositioned at the top of the scroll bar for maximum speed, and the
PARENT button was repositioned to the far left corner and reduced in
size.

AMOS 1.23

Added the SERIAL extension, SPRITE compactor and procedure locking
utility.

AMOS 1.3

The latest version of AMOS Basic is version 1.3.  This comes with the
compiler and includes a range of turbo-charged Bob and screen copy
routines from the mind of Gary Symons.  These optimise the performance of
commands such as SCREEN COPY and PASTE BOB/ICON, leading to dramatic
speed improvements in many games.
        All the above features from V1.1 onwards, exist in V1.3.  This
supplement manual will provide you with the information to access all
these new additions to AMOS.


BOB FLIPPING COMMANDS
In a great number of games, the main character needs to animate left to
right, and up and down.  Up to now, you were obliged to keep in the
sprite bank reversed copies of small animation sequences for the main
character.  As the main character usually has the best animation, you
lose an enormous amount of space!
        For the game RanXerox, for which AMOS author Francois Lionet wrote
the sprite routines, a flipping routine was developed which allowed just
one copy of the main character to be kept in the bank.  This routine has
been enhanced and placed into AMOS.
        How does it work?  Imagine your character is walking to the left and
then back to the right.  You would only have in your bank the image of
him walking to the right.  To display this right image, you simply refer
to the image number in the bank as usual.
        To display the image reversed in the X axis (left walking image),
you set bit number 15 of the image number to 1.  Don't panic, you can
simply do it with:

        $8000+Image number

So:

        Bob 1,160,100,1

will display your character walking right, and:

        Bob 1,160,100,$8000+1

will display it walking left.  The same principle is used for vertical
reversing.  For this, bit number 14 is used - add $4000 to the image
number.  To have vertical and horizontal reversing, use $C000.
        The symmetry is a full symmetry:  The hot spot of the bob is also
reversed.  For example, if we put the hot spot in X under the feet of our
character, the reversed version would also have it under his feet.  So be
careful if you set the hot spot on the top left corner on a bob, the
reversed image will be displaced at the top left!
        You might say that $8000 and $C000 are a bit weird to use.  We have
provided special functions to give a better AMOS interface:

        =HREV(image)            adds $8000 to the image
        =VREV(image)            adds $4000
        =REV(image)             adds $C000

Use them in place of the hex values:

        Bob 1,160,100,10
        Bob 1,160,100,HREV(10)
        Bob 1,160,100,VREV(10)
        Bob 1,160,100,REV(10)

To allow easy use of the bob flipper in AMAL, we have implemented
HEXADECIMAL evaluation.  So you can use hex notation to refer easily to
reversed bobs.  If hex frightens you, just add $8000, $4000 or $C000
before all references in your AMAL strings.

Example:

Old AMAL string:

        "Anim 0,(1,2)(2,2)(3,2)(4,2)"

New reversed string:

        "Anim 0,($8000+1,2)($8000+2)($8000+3)($8000+4)"

or

        "Anim 0,($8001,2)($8002,2)($8003,2)($8004,2)"

If you use a register to calculate the image number, do not try to modify
the calculation itself, but only when you assign the register to the
image.

Old AMAL string:

        For R0=1 To 10; Let A=R0; Next R0

New one:

        For R0=1 To 10; Let A=$C000+R0; Next R0


HOW DOES THE FLIP ROUTINES WORK?
It is really important for you to understand how it works internally, so
that you do not ask this system to do things it is not designed to do.
        The reversing system is designed to free memory before trying to be
fast (although we would not mind if it was actually fast, would we?).
Concessions had to be made to have it fast, and at the same time easy and
powerful.
        The routine actually works right in the middle of the bank, and does
not use any extra memory.  The bobs are flipped during the UPDATE
process, just before a bob is redrawn on the screen.  AMOS looks to see
if the image needs to be flipped in the bank.  If it does, it is flipped
and a flag is set within the bank.  On the next UPDATE, if the bob image
has not changed, it will be flipped, thus saving a lot of time.

If you understand the above, you will realize one BIG limitation.  It is
not wise to use more than one flipped bob pointing to the same image.
Let's see the next example:

        Bob 1,160,100,1
        Bob 2,160,150,$8001
        Bob 3,20,20,$4001
        Bob 4,20,100,$C001
        Update

During the UPDATE process, AMOS will first draw bob number 1.  No
problem, it is in the right position.  Then bob number 2 - AMOS needs to
reverse it in X.  Bob number 3 needs a Y and an X reversing (to put the
bobs back to normal in X!).  Then bob number 4 needs an X flipping.
        On the next update, providing the bob's image has not changed, to
display bob 1, AMOS will have to flip it in X and Y, then bob 2...
        As you can see, for each UPDATE, that is, every 50th of second, if
the bobs move they need to be reversed!  This will work, but will take a
lot of processor time, and the animation will be disastrous.
        So the golden rule is, use the reversed bobs for object alone on a
screen (or be sure that normal and reversed images are not displayed at
the same time on the screen).  If you want, you can have two bobs like
this - experiment!
        We told you before that this system was for use with bobs.  Yes, it
is totally automatic with bobs.  But as it directly affects the sprite
bank, you can also use it with sprites.
        When a hardware computed sprite is calculated, AMOS looks into the
sprite bank and gets the image from it.  If the image is reversed at that
moment, the hardware sprite will display a reversed image.  You can
therefore have reversed hardware sprites using this method.  But you
cannot do this for example:

        Sprite 1,200,200,$8001

PASTING FLIPPED BOBS
PASTE BOB also accepts reversed images.  A simple trick to reverse an
image in the bank without having to display a bob, is to PASTE the
reversed image outside of the screen.  Example:

        Paste Bob 500,500,$C000

This will reverse image 4 in the bank, without any output (and quite
fast).

COLLISION DETECTION
This is an important point, and you have to be very careful when you
detect collisions with reversed bobs!
        The collision detection uses the shapes in the bank at the very
moment it is called.  Let's see an example that will never work:

        Bob 1,160,100,1

        Do
          Bob 2,XScreen(XMouse),YScreen(YMouse),$8001
          Wait Vbl
          Exit if Bob Col(1)
        Loop

Why doesn't it work?  We have two reversed images of the same definition
in the bank.  After the updating process, the image in the bank is left
reversed.  So the Bob Col instruction will take bob shape 1, the reversed
image, and this will not work!
        So remember: THOU SHALT NEVER USE COLLISION DETECTION WITH MORE THAN
ONE REVERSED IMAGE ON THE SCREEN!

HOW IS IT CODED INTO THE SPRITE BANK?
Two bits of each images X Hot Spot are used to flag the flipping (at
SPRITE BASE+6).

Bit number 15 for X             0 if normal, 1 if reversed
Bit number 14 for Y             0 if normal, 1 if reversed

Before RUN and SAVE, the bank is restored to its normal state, so that it
is still compatible with version 1.1.

BLOCK FLIPPING
The flip routine can be used for blocks.

HREV BLOCK (Flip a block horizontally)

HREV BLOCK image

Flips block number IMAGE horizontally.

VREV BLOCK (Flip a block vertically)

VREV BLOCK image

Flips block number IMAGE vertically.

SQUASH A BOB ROUTINE
This routine was originally written for a Fun School 3 program called
Letters.  Each letter in the alphabet is displayed as a single large
sprite.  This requires a total of 52 separate images, taking up a massive
110k of memory.  Since only a couple of images are displayed at a time,
most of this space is actually wasted.  So a small routine was written to
pack the unused sprites into a spare memory bank.  This allowed us to
compress the entire sprite bank into just 26k!
        AMOS Squash is now available on the public domain.  Feel free to use
it in any of your own programs.  It's especially useful for the massive
Level Guardians in an arcade game.  These can be compressed into a
fraction of their normal size, and can be instantly retrieved at the
appropriate point in your program.

USING AMOS SQUASH
The packer program comes in two separate parts.  The first program loads
a sprite bank into memory and compacts your images.  It can be found in
the file 'Squash_a_bob.AMOS'
        In order to use this routine, you need to perform the following
simple procedure:

  *     Load a sprite bank from the disk using the file-selector.
  *     Enter the number of the FIRST sprite you wish to pack.
  *     Enter the number of the FINAL sprite in your list.
  *     Input the number of colours used by your sprite images.
  *     Choose a new memory bank to hold your squashed images.

The squasher routine will now be executed and your selected images will
be quickly compressed.  After it has concluded, you will be given an
option to save your compacted images onto the disk.
        Note that NO colour information is saved with these images.  So you
may need to make a note of the current colour settings before proceeding
any further.
        Once you've squashed your images, you can load them into your AMOS
Basic programs with the help of three small procedures.  These can be
found in the file 'Squash_procs.AMOS' and can be incorporated using the
MERGE command from the AMOS Editor menu.
        The squash routines are remarkably easy to use.  The first stage is
to load your original sprite bank from Direct mode and delete the images
you have just compressed.  Use a line like:

        Del Sprite start To finish

This erases your old images from memory, saving you considerable amount
of storage space.  You can now enter your packed images from the disk
with the LOAD command:

        Load "images.abk"

At the start of your program, you should initialise the compaction system
with a call to the PBOB_INIT procedure:

        PBOB_INIT[bank,cols,max_x,max_y]

Where:

        bank            is the bank number containing your compressed images
        cols            holds the number of colours
        max_x   stores the maximum width of your images
        max_y   holds the maximum height of your images

The action of this procedure is to prepare a temporary screen for the
squasher utility.  Your images can now be unpacked as and when they are
required, using a simple call to the PBOB routine.

        PBOB[source,dest]

'source' is the number of the image to be unpacked.  This is the original
image number from the sprite bank.
'dest' is the number of the new image you wish to install in the sprite
bank.  Choose the number of the last sprite in the bank plus one.
        Once you've installed your image into memory, you can animate it
directly with the various SPRITE or BOB commands.  PBOB can be called as
many times as you wish.  So the same image number can be re-used again
and again.
        Finally, add a call to the PBOB_END procedure towards the end of
your program.  This will erase the hidden screen created by PBOB_INIT.


SERIAL PORT COMMANDS EXTENSION
Welcome to the intriguing world of AMOS communications.  The serial
extension is intended for those of you who wish to transfer information
between several different computers using the Amiga's serial port.
        The extension provides you with a total of 15 new commands.  You can
use these commands to create amazing multi-user games.  It's also
possible to access a Midi interface which has been plugged into the
Amiga's serial port.  So musicians will be able to control their
instruments directly from AMOS Basic.  Wow!  As you would expect, full
multitasking is supported.


OPENING THE SERIAL PORT

SERIAL OPEN (Opens a channel for Serial I/O)
SERIAL OPEN Channel, Port_no [,Shared, Xdisabled, 7wires]
Opens a communication channel to a serial device.

'Channel' This is an identification number which will be used for all
subsequent communication commands.  Allowable values range from 0 to 3.

'Port_no' Specifies the logical device number of the serial port.
Normally, this value should be set to zero.  However, if you've plugged a
MULTI SERIAL card into your Amiga, you can access your additional ports
using the numbers from one onwards.

'Shared' (optional)  This is a flag which informs AMOS that the device
can be shared with other tasks which are currently running on your Amiga.
It's used in multitasking.  A value of FALSE (zero) will grab the channel
for AMOS Basic, and will deny access to any other programs.  If it's set
to TRUE (-1), the serial port can be shared between several programs in
memory.  Beware: This system must be used with extreme care or the Amiga
could easily crash!

'Xdisabled' (optional) Toggles XON/XOFF checking during transmission of
your data over the serial line.  It's essential to set this flag when you
are first opening the device, even if it will only be required later.
The default value is FALSE (0) and disables the system.  If you want to
enable the checking, use the value of TRUE (-1).  After the port has been
opened, you'll then need to set the XON and XOFF characters using a
seperate call to the SERIAL X command.

'7wires' (optional) A value of TRUE (-1) tells the device to use the 7
wires system as explained in the official Commodore documentation.  The
default is FALSE (0).

When you call the Serial Open command for the first time, it will
automatically load the SERIAL.DEVICE library from your system disk.  So
make sure it's available from the current drive.
Incidently, the default serial settings use the French Minitel protocol:
1200 Baud, 7 bits, 1 stop bit, Even parity.  This can easily be changed
using the SERIAL SPEED, SERIAL BIT or SERIAL PARITY instructions if
required.


CLOSING THE SERIAL PORT
SERIAL CLOSE (Closes one or more serial channels)
SERIAL CLOSE[Channel]
If you don't include the channel number, SERIAL CLOSE will close all
currently opened serial channels with absolutely no error checking.  The
optional channel number allows you to close a single channel and use all
the normal error checks.

NOTE: Whenever a program is RUN from AMOS Basic, any opened channels will
be automatically closed for you.


SENDING INFORMATION THROUGH THE SERIAL PORT

SERIAL SEND (Output a string via a serial channel)
SERIAL SEND Channel, t$
Sends the string t$ straight to the specified serial channel.  It does
not wait for the data to be transmitted through the actual port.  You'll
therefore need to use the =SERIAL CHECK(Channel) function to detect when
the transmission has been completed.

SERIAL OUT (Outputs a memory block via a serial channel)
SERIAL OUT Channel, Address, Length
This is identical to Serial Send except that it works with RAW data.

'Address' is the address of your data in memory.
'Length' is the number of bytes to be sent.


READING INFORMATION FROM THE SERIAL PORT

SERIAL GET (Gets a byte from a serial device)
=SERIAL GET(Channel)
Reads a single byte from the serial device.  If nothing is available a
value of -1 will be returned.

SERIAL INPUT$ (Get a string from the serial port)
=SERIAL INPUT$(Channel)
Reads an entire string of characters from the serial port.  If there's no
data, the command will return an empty string "".  Otherwise the string
will contain all bytes which have been sent over the serial line up to
the present time.
        Be careful when using this command with high speed transfers (such
as MIDI).  If you wait too long between each SERIAL INPUT$ command, you
can overload the system completely, and generate annoying errors such as
'string too long' or 'serial device buffer overrun'.


SETTING THE SERIAL PARAMETERS

SERIAL SPEED (Sets the transfer baud rate for a serial channel)
SERIAL SPEED Channel, Baud rate
Sets the current transfer rate of the appropriate channel.  The same
values will be used for both reading and writing operations.  Note that
you can't set split baud rates for a single channel.  If the baud rate
you have specified is not supported by the current device, it may be
rejected by the system.

SERIAL BIT (Sets the Nbit & Stopbit part of a protocol)
SERIAL BIT Channel, Nbits, Stopbits
Assigns the number of bits which will be used for each character you
transmit.

'Nbits' is the number of bits
'Stopbits' is the number of STOP bits

SERIAL PARITY (Sets the parity checking)
SERIAL PARITY Channel, Parity
Sets the parity checking you are using for the current serial channel.
Here's a list of the available options:

Parity<0:  No parity
Parity>0:  Only the first two bits of this value are significant.

Bit 0:          =0->EVEN
                        =1->ODD
Bit 1:          =0->Normal parity
                        =1->SPACE

The paruty bit can be set using the BSET or BCLR function like so:

        P=0: Bset 0,P: Rem Odd parity
        Bclr 1,P: Rem Normal parity
        Serial Parity 1,P: Rem Set the parity using the value in P

See the Commodore's documentation for a full explanation of this system.

SERIAL X (Sets XON/XOFF)
SERIAL X Channel, Xmode (Activates/deactivates the XON/XOFF handshaking
system)
A value of TRUE for Xmode disables handshaking.  Any other value turns it
on.  Xmode should be loaded with the correct control characters.  These
must be specified in the following format:

        Xmode=XON*$10000000+XOFF*$10000

Check Commodore's documentation for more information.

OTHER COMMANDS

SERIAL BUFFER (Sets the size of the serial buffer)
SERIAL BUFFER Channel, Length
Allocates Length bytes of buffer space for the required channel.  Note
that the default value is 512 bytes and the minimum allocation is 64
bytes.

It's a good idea to increase the buffer size for high speed transfers.

SERIAL FAST (Switches on FAST transfer mode)
SERIAL FAST Channel
This sets a special fast flag  in the current device and disables a lot
of internal checking which would otherwise slow down the communication
process.  Use it for high speed transfers such as MIDI.

WARNING: When you call this command, the protocol will be changed to:
PARITY EVEN, NO XON/OFF and 8 bits.

SERIAL SLOW (Switches serial transfer back into SLOW mode)
SERIAL SLOW Channel
Slows the serial device back to normal speed and reactivates all the
error checks.

SERIAL CHECK (Reports on current serial device activity)
=SERIAL CHECK(Channel)
Asks the device for a read-out of its current status.  You can use it to
check whether all the information you've transmitted with a previous
SERIAL SEND command has been sent.

        CHECK=FALSE (0) -> if the last serial command is still being
        executed.

        CHECK=TRUE (-1) -> All done!

SERIAL ERROR (Reports success or failure of last transfer)
=SERIAL ERROR(Channel)
Looks for the ERROR byte in the serial device.  A value of zero indicates
that everything is fine.  Otherwise, the last transmission was faulty.


SENDING LARGE STRINGS
Transmitting a large string may taike quite a long time, especially at
low baud rates.  As AMOS is multitasking, your program will continue to
run AFTER a SERIAL SEND instruction.
        It's essential to avoid provoking a garbage collection before the
transfer has been completed, otherwise your data will be corrupt.  So:

  *     Use the =SERIAL CHECK function before doing a lot of string work.
  *     Perform a garage collection using X=FREE to ensure that your
        program will not provoke one automatically.
  *     Use the SERIAL OUT channel, address, length instruction with
        'address' containing the location of a previously reserved memory
        bank.

MORE INFORMATION
More information about the Amiga's serial system can be found in the
Commodore ROM KERNAL Referance Manual, Library and Devices.  This will
allow expert users to make maximum use of the serial device.


MULTI TASKING IMPROVEMENTS

MULTI WAIT (Force a multi-task wait vbl)
MULTI WAIT
To make effective multi-tasking programs, you must not grab most of the
processor time, leaving only a limited amount of power for other tasks.
MULTI WAIT does MULTI-TASK wait vbl.  You should use it in your program's
main loop, when you wait for example, for a menu unit item to be
selected.
        Note that you should not use this instruction to make accurate
screen synchronisation as it is designed to multi-task.  This instruction
is NOT consistant at all!  It may skip many VBLs, depending on the number
of running tasks at the time.
        If you missed it elsewhere in the manual, multitasking can be
activated by pressing Amiga+A to flick between AMOS and the CLI or
Workbench environments.  This allows systems with at least 1 meg to run
AMOS and programs like DPaint III at the same time!

AMOS TO BACK (Hide AMOS from view and show the Workbench)
AMOS TO BACK
This will bring forward the Workbench display, allowing you to access
other programs.

AMOS TO FRONT (Switch AMOS to the display)
AMOS TO FRONT
AMOS is forced back onto the display with this command, leaving the
Workbench hidden.

AMOS HERE (Report which task is on display)
AMOS HERE
This returns TRUE if AMOS is currently displayed and FALSE if the
Workbench is in view.


LOAD AMOS FROM WITHIN A FOLDER
AMOS does a number of housekeeping chores before fully loading up and
presenting itself to you.  One of these is to locate all its default
files like the sprite pointer, default font and so on.  The procedure and
logic is as follows:

1  Check the current system to define if a PAL or NTSC screen is in use.
2  Depending on the system it will look for the AMOS1_3_PAL.Env or
   AMOS1_3_NTSC.Env.
3  Failing to find one of these files, it will look for the AMOS System
   folder in the root directory of the current drive.  If this also
   fails, AMOS gives up trying to load and returns to the Workbench.
4  If AMOS picks up Default.Env at point 2, it will examine the
   environment file to find where the other files are located.  This is
   the key to relocating AMOS anywhere on a disk.

Let's assume we want to set up AMOS within a folder called UTILS on a
hard disk.  First we must copy across the following files from the AMOS
Program disk to the hard disk path Dh0:UTILS/

        AMOS_System             A folder containing all the default files
        AMOS1.3                 The main AMOS file

The files AMOS1_3_PAL.Env and AMOS1_3_NTSC.Env must be moved from the
AMOS System folder to the Utils folder.

        AMOS_System
        AMOS1.3
        AMOS1_3_PAL.Env
        AMOS1_3_NTSC.Env

Now we must change the Env files so that they tell AMOS where all the
data files are.  To do this you'll have to boot a normal copy of AMOS and
run the Config.AMOS program.  Simply ensure that the loaded extensions
and default files have the correct path and filenames.
        In our example all the files are inside the directory AMOS_System.
Just make sure that the extensions you have read as follows.

        1-AMOS_System/Music
        2-AMOS_System/Compact
        3-AMOS_System/Request
        4-AMOS_System/3D
        5-AMOS_System/Compiler
        6-AMOS_System/Serial

The default filenames must be set as:

        1-AMOS_System/Def_Icon
        2-AMOS_System/Mouse.Abk
        3-AMOS_System/Defaukt.Font
        4-AMOS_System/Default.Key

An important point to note is that only the extra part of the pathname is
required.  AMOS adds AMOS_System onto the current path (in this case
Dh0:UTILS/AMOS_System/
        Hard disk users will find this information very helpful and it will
avoid having the AMOS_System folder stuck in the root directory of the
hard disk.  Anyone developing a CDTV application in AMOS will also need
to use this feature.  The above information is also true for the RAMOS
runtime system, the only difference being that RAMOS doesn't require PAL
or NTSC files.

INTERLACED SCREEN MODE SUPPORT
To open an interlaced screen use the following syntax:

SCREEN OPEN 0,320,200,16,LACED [+HIRES][+LOWRES]

LACED is a function that returns 4.

Important:  As soon as one screen is opened with interlace, all the other
screens turn to interlace.  The interlacing will only truly effect the
screen actually opened with LACED.  All the others will just have their
vertical lines doubled on the screen to adjust to the special mode.
        Interlaced mode is perfect for displaying pictures, but animation
runs at half normal speed.  Games should not be written in Interlace!
        As soon as the last interlaced screen is closed the whole display
returns to normal mode.  Your TV monitor might not like lots of fast
switching from normal mode to Interlace, so you are adviced not to do
this excessively.
        All normal operations are available in interlaced screens:  Screen
Offset, Screen Display and so on.  The only problem that arises is due to
interlacing being software driven in AMOS.  The bitplanes are changed
during the vertical blank and this particular interlace process is
forbidden during copper list calculation.
        So if you have a large copper list file (ie. four screens, one
interlaced, and a rainbow), and have a copper calculation to do, the
interlaced screen will display only half of the picture during the
calculation.  Nothing can be done to solve this, it is simply a
limitation of the whole system.

There are two extra screen commands in AMOS now.  These allow a program
to work out what type of display it is being run on:

DISPLAY HEIGHT (Report how tall a screen can be)
=DISPLAY HEIGHT
This command returns 311 in PAL and 263 in NTSC.

NTSC (Flags the type of display in operation)
=NTSC
This returns TRUE if the system is in NTSC mode or FALSE if in PAL.
Ideal for international software development!
        NTSC refreshes the screen at 60 times a second whereas PAL refreshes
at only 50 times a second.  However, AMOS1.3 compensates for this and now
music runs at exactly the same speed in PAL and NTSC
        AMAL also relies on the interrupt routine but is not slowed down to
comply with PAL speeds.  You must therefore be careful not to synchronise
music and animations by just relying on the speed they run at.  Check
that an animation frame has been reached or the music has played a
certain note.  Using this technique you'll ensure the software executes
at the right point on all systems.


OTHER NEW AMOS COMMANDS

NEW SYSTEM REQUESTER EXTENSION

REQUEST (Generates a requester routine)
REQUEST ON
This will make AMOS generate its own requester routine and is the
default.

REQUEST OFF
AMOS will always select CANCEL button of the requester if this command is
used.  The actual requester will not be displayed, so this ideal for
error trapping within a program.

REQUEST WB
This tells AMOS to switch back to Workbench's system requester.  You'll
come back to AMOS as soon as you have chosen one of the options.

Note:  If you don't load up the Requester (by deleting it from the
extension list using the config file), the normal Workbench requester
will be used for displaying messages.

This does have a bad side-effect though, AMOS will seem to have crashed
when a requester appears.  If this happens you simply press Amiga+A to
return to the Workbench, answer the question and press Amiga+A once again
to return to AMOS.  It's only best to avoid loading the requester when
the memory is very low!

ALTERING THE BOB DRAWING ORDER

PRIORITY REVERSE ON/OFF (Change the order in which Bobs are printed to
                                        the screen)
PRIORITY REVERSE ON
PRIORITY REVERSE OFF

PRIORITY REVERSE ON, reverse the entire bob's priority table.  This means
that bob number 1 will be the first one drawn in front of all other bobs,
2 will come in second etc...  This priority list is compatable with STOS.
        This instruction has another feature when used in conjection with
the PRIORITY ON command.  The bobs are not printed from TOP to BOTTOM any
more, but from BOTTOM to TOP!  The highest bob on the screen will be
displayed in front of the others.

SWAPPING BANKS
A new and very needed instruction:

Bank Swap number1, number2

This instruction will swap the pointers of the two banks.  Useful if you
want to turn an icon bank into a sprite bank.  Example:

        Bank Swap 1,2

or have more than one music bank at the same time, for example:

        Bank Swap 3,5


SEARCHING FOR THE CURRENT DEVICES
AMOS can report back to you the current list of devices using the
following commands.

=DEV FIRST$ (Get first device from current device list)

dev$=DEV FIRST$("filter")

Works the same as Dir First$ and Dir Next$, but reports back the device
list.  Note that you should remove the spaces with - "" to get the right
name.

=DEV NEXT$ (get the next device satisfying the filter)

dev$=DEV NEXT$

Gets the next device from the device list.  A null string indicates the
end of the list has been reached.  Example:

        Print Dev First$
        Do
          A$=Dev Next$
          A$=A$-""
          If A$=""then End
          Print A$
        Loop


THE FUTURE OF AMOS
AMOS will constantly be updated so that it keeps up-to-date with new
trends on the Amiga scene.  For the latest AMOS update information
contact:
Sandra Sharkey of the AMOS PD Library:
25 Park Road, Wigan, WN6 7AA, England.
Telephone 10am to 3pm on [phone]

End.